Data cube high availability

ABSTRACT

The subject disclosure is directed towards making cube data highly available and efficient to access by separating the read cube server from the processing cube server, on different physical machines. The read cube server may be mirrored, and the write cube server may be mirrored. When the primary read cube server is not operational (e.g., has failed) or is having its read cube synchronized, the read queries are handled by the mirror read cube server. When a processing cube server (or its write cube) is not operational, its mirror processing cube server takes over and performs cube processing operations via its mirror write cube.

CROSS-REFERENCE TO RELATED APPLICATIONS

The application is a continuation of, claims the benefit of and priorityto, previously filed U.S. patent application Ser. No. 12/945,950entitled “Data Cube High Availability” filed on Nov. 15, 2010, thesubject matter of which is hereby incorporated by reference in itsentirety.

BACKGROUND

A data cube, such as a Microsoft® SQL Server Analysis Services cube, isa three-dimensional (or higher) database structure for storing andpresenting data. Users of such a cube want their data to be highlyavailable, with minimum interruptions in the event of hardware orsoftware faults. However, there was heretofore not any consistent way toensure highly available cubes, including highly available cubes in whichdata access remains efficient, even in heavy traffic.

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, various aspects of the subject matter described herein aredirected towards a technology by which a read cube server that handlesread queries runs on a separate machine from a processing cube serverthat handles writes (data changes). Moreover, the read cube server maybe mirrored, and the processing cube server may be mirrored. As a resultof handling reads and writes on separate, mirrored machines, cube datais highly available and access to that data is efficient.

In one aspect, a primary read cube server handles incoming read queriesby returning data from a primary read cube. When the primary read cubeserver is not operational or when the primary read cube is beingsynchronized, a mirror read cube server coupled to a mirror read cubehandles the incoming read queries by returning data from the mirror readcube.

The primary processing cube server coupled to a primary cube servicewrites change data to a primary write cube, and (e.g., periodically)synchronizes the mirror write cube and the read cubes based upon thechange data. When the primary processing cube server and/or the primaryprocessing cube is not operational, a mirror processing cube servertakes over, writes data changes to the mirror write cube, andsynchronizes the primary read cubes.

In one aspect, handling read queries (e.g., at a front end servercomponent) includes determining whether a first read server having afirst read cube is currently capable of handling the queries. If so, thequeries are directed to the first read server; if not, the queries aredirected to a second read server having a second read cube. For example,the front end server component decides that the first read cube serveris not currently capable of handling the queries if the first readserver is non-operational or if the first read cube is currently beingsynchronized.

Cube write data may be processed by a mirrored processing server, havinga first cube service that synchronizes the read cubes and a mirror writecube. A mirror processing cube service takes over for the firstprocessing cube service when the first processing server or the firstwrite cube is not operational.

Other advantages may become apparent from the following detaileddescription when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 is a block diagram representing an example architecture havingprimary and mirror read cube servers and read cubes that are separateand independent from primary and mirror processing cube servers andwrite cubes.

FIG. 2 is a block diagram representing the example architecture in FIG.1 in which the primary read cube server has failed over to the mirrorread cube server.

FIG. 3 is a block diagram representing the example architecture in FIG.1 in which the primary processing cube server has failed over to themirror processing cube server.

FIG. 4 is a flow diagram showing example steps that may be performed bya cube service running on a processing cube server.

FIG. 5 is a block diagram representing exemplary non-limiting networkedenvironments in which various embodiments described herein can beimplemented.

FIG. 6 is a block diagram representing an exemplary non-limitingcomputing system or operating environment in which one or more aspectsof various embodiments described herein can be implemented.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generallydirected towards providing high cube data availability with efficientoperation for users (e.g., customers) in a datacenter environment. Tothis end, an architecture is provided including a dedicated server forcube data processing (e.g., an active processing cube server) and adedicated server to which the front end servers query for cube data(e.g., an active read cube server). Further, the cube data processingserver has a mirror (standby/backup) server, and the cube read serverhas a mirror server. Each of the servers corresponds to its own machine(or machine cluster), so that a hardware failure does not stop queryprocessing or change data (write) processing.

As will be understood, the technology works on the concept of separatingthe cube processing server from the cube querying server, whereby cubeprocessing does not affect the availability of the read cube. As aresult, the architecture/pipeline that provides updated customer data inreal time remains established, even if one of the processing servers isnot available (whether crashed or temporarily unavailable), or one ofthe read servers is not available (whether crashed or temporarilyunavailable).

It should be understood that any of the examples herein arenon-limiting. For one, while “mirror” servers are described in theexamples, a “mirror” server is not limited to a single standby server,and indeed may comprise more than one standby server, e.g., a thirdserver may take over operations if the other two are not available, andso on. As such, the present invention is not limited to any particularembodiments, aspects, concepts, structures, functionalities or examplesdescribed herein. Rather, any of the embodiments, aspects, concepts,structures, functionalities or examples described herein arenon-limiting, and the present invention may be used various ways thatprovide benefits and advantages in data storage and processing ingeneral.

FIG. 1 shows example components of the architecture/pipeline forhandling user queries directed towards a data cube. In FIG. 1, a frontend server 102 (comprising one or more machines) receives queries,(e.g., MDX, or multidimensional queries each represented by Q), and inthis example directs the read queries to a read cube 104 a of theprimary active read cube server 106 a. Note that FIG. 1 shows theprimary active read cube server 106 a on the left of the diagram and themirror active read cube server 106 b on the right, however as describedherein, the servers may change roles, e.g., what is shown as the primarymay become inactive, whereby the mirror becomes active.

To determine to which server to direct the queries, a component (e.g.,business logic layer) 108 at the front end server 102 makes a SQL queryto the SQL database 110 a to determine the state of the active read cube104 a; (note that the SQL databases are mirrored via its own, knowntechnology). If the server 106 a is not operational (in which event SQLindicates that the mirror database 110 b was used), or is beingsynchronized (in which event SQL returns the state from the database 110a as “sync in progress”), then the layer 108 directs the queries Q tothe other, currently passive read cube 104 b (which now becomes active).Otherwise, (that is, the database returned “sync not in progress”), thelayer directs the queries Q to the read cube 104 a, which is active.Note that in the event that the synchronization is occurring on theprimary read cube server 106 a and the mirror read cube server 106 b isnot operational, then the read queries are blocked or held until thesynchronization completes.

With respect to handling write data, the cube service 114 a waits fornotification for changes in the SQL database 110 a and updates thosechanges into the active processing write cube 118 a. Occasionally, e.g.,periodically, the cube service 114 a performs incremental dataprocessing (or full cube processing if necessary) on the primaryprocessing cube server 116 a. On a notification to process incrementaldata, if the cube server 116 a has failed, the cube service 114 b takesover to perform the incremental processing.

Before performing any incremental processing with the database 110 a,the cube service 116 ensures that the processing cube 118 a issynchronized with the last updated data in the database 110 a. To thisend, at the end of processing of the cube 118 a, the cube service 116uploads a timestamp into the database 110 a and into the cube 118 a.This timestamp is used on the next synchronization to determine whetherthe cube 118 a is synchronized with the database 110 a. If the cubeservice 114 a determines that the cube 114 a is not synchronized withthe database 110 a, the service 114 a performs a full processingoperation instead of an incremental processing operation.

To summarize, the synchronization operations and synchronization stateis controlled by the cube service 114 a or 114 b that is currentlyoperational. For example, in FIG. 1 the cube service 114 a of theprocessing cube server 116 a is currently operational. The write cube118 a maintains the write data that is to be synchronized to the othermachines, which is regularly performed as needed, e.g., periodicallysuch as every few minutes.

In one implementation, synchronization proceeds in a specific sequence,represented in FIG. 1 by the arrows labeled with circled numerals onethrough three. First, the write cube 118 b is synchronized with the dataon the write cube 118 a; this allows the mirror processing cube server116 b to take over (as described below) in the event of failure of theprimary processing cube server 116 a. Secondly, the read cube on theread cube server that is not actively servicing read queries issynchronized, e.g., the read cube 104 b on the read cube server 106 b.Thirdly, the other read cube (104 a in this example) is synchronized. Asmentioned above, when a read cube is synchronized, its machine's SQLdatabase is marked as “synch in progress” so that queries are directedto the other read cube server during the synchronization process. Thesynchronization sequence ensures that even if a failover happens, theusers always get data which is not older than that in the currentprimary read server. Alternative synchronization operations arepossible, e.g., in parallel at least to an extent.

The synchronization order ensures that the processing mirror cube issynchronized even if the read cubes are not, whereby if a failover ofthe cube service (or the processing machine) occurs, the mirrored thecube service incrementally processes from there, without having to issuea full cube process. Further, after the read mirror cube issynchronized, if there is a read cube failover, the read queries aredirected from the read primary cube to the read mirror cube. Because theread mirror cube is synchronized before the read primary cube, thecustomer starts getting recent data even after failover (instead ofgetting old data instead of new if the read cube synchronization orderwas reversed).

Note that in FIG. 1, the dashed arrows represent the samesynchronization operations when the cube service 114 b of the mirroractive processing cube server 116 b is in control. Failure of aprocessing server transfers control, as described below. Note that thedatabases 110 a and 110 b maintain information as to which cubeprocessing server 116 a or 116 b is currently in control, as well aswhich cube read server 106 a or 106 b is currently active.

FIG. 2 represents various aspects of failure of a read cube server,shown by the crossed-out lines over server 106 a. As described above,the layer 108 of the front end server 102 reads the synchronizationstate maintained in the database 110 a, which in normal operation is“synch in progress” or “synch not in progress.” In the event of afailure, the SQL query result indicates that the mirror database 110 bwas read, and thus that the mirror read cube server 106 b is active.Also, the cube service 114 a can listen to database failover events,e.g., by monitoring for the failover of the SQL database to know whichmachine has the primary database and which has the mirror database.

If the state is “synch in progress” then read queries to be directed tothe cube 104 b are blocked/held until the synchronization completes and“synch not in progress” is written by the processing cube server. Thus,when the primary read query server 106 a goes down, the mirror querycube server 106 b takes over servicing queries. For the (very small)window of time when cube synchronization may be in progress at theactive read cube server, queries to this server are blocked until thesynchronization operation is complete.

FIG. 3 represents various aspects of failure of a processing cubeserver, shown by the crossed-out lines over the server 116 a. Note thatthis may be because of a crash, or because an operator intentionallydecides to switch off the machine, e.g., for maintenance, (although forintentional maintenance, it may be desirable to first move the serviceinto a pause mode which occurs only after completing or cancelling anycurrent transaction). In any event, on failover the mirror processingcube server 116 b takes over the active role.

As part of performing its operations, the active processing cube server(e.g., 116 a) writes a schedule of operations to perform to the database110 a, and begins performing the scheduled operations. In the event thatthe processing server 116 a goes down, the mirror processing server 116b detects this non-operational state (via a known mechanism) and takesover, whereby users will still have the latest data surfaced to the readcubes. When the mirror processing server 116 b takes over the principalrole, the mirror processing server 116 b continues processing theschedule from where the failed server 116 a left off.

Another type of failure is that of the primary processing cube 118 a. Ifthis cube 118 a is not operational, e.g., unavailable or fails for somereason, the cube service 114 a tries to re-connect to update it. If thecube service 114 a fails to update the processing cube 118 a, the cubeservice 114 a may raise an event to notify an administrator/operator,and the update attempt fails some number of times, e.g., three, the cubeservice 114 a exits to allows the mirror cube service 114 b to take overthe active role, with the backup processing cube 118 b being active. Asused herein, “not operational” refers to the service and/or the cubefailing for any reason, whether unintentional (e.g., a machine crash),intentional (e.g., the machine is taken down for maintenance) or for anyother reason (e.g., the service has a bug, the cube is non-responsive,and so on). Similarly, “not operational” refers to the read cube servermachine or any of the components therein being in a failed state for anyreason.

Turning to another aspect, the read cube sometimes needs to be rebuiltin its entirety from the SQL database, such as if the SQL databasecrashes and is restored from a backup. More particularly, when a SQLdatabase is backed up, there is no guarantee that the backed SQLdatabase and the cube database are synchronized, and thus whenever theSQL database is restored, the cube service needs to perform full cubeprocessing to ensure that it is synchronized with the restored database.

Rebuilding of the processing cube may take a relatively long time, onthe order of hours. However, this does not affect the performance of theread cube, because it is independent, on a separate machine. Similarly,long running queries handled by the read cube server do not affect theperformance of cube processing on the processing cube server, becausecube processing is independent of query handling and is performed on aseparate machine.

The following table provides example fields that may be maintained onthe mirrored SQL database 110 a and 110 b:

Allow Column Name Type Null Description Cube Label nvarchar(100) No Atthe end of incremental processing or full processing, a label ortimestamp will be applied in both SQL database and Cube. IsFullCubePro-Bool No True when full cube cessingInProgress processing progressFullCubePro- Datetime Yes Update time as the cessingStartTime beginningof full cube processing FullCubePro- Datetime Yes Update time at the endcessingEndTime of full cube processing LastIncremen- Datetime Yes Updatetime at the end talProcessingTime of each incremental processingIsInPauseMode Bool No True if cube is requested in pause mode and cubeservice has agreed to this setting IsAutoSyncEnabled Bool No True ifcube service is expected to sync to querying server after processing.

FIG. 4 is a flow diagram showing example steps of the cube service whenrunning. In general, the cube service operates based upon notifications,as represented in FIG. 4 via block 402. If the notification is anadministrator command, as evaluated at step 404, the command isprocessed at step 406.

If the command is an incremental processing notification as evaluated atstep 408, at step 410 the cube service processes the cube with theincremental data corresponding to the notification. Note that althoughnot explicitly shown in FIG. 4, as described above the processingrepresented by step 410 may fail if the write cube has failed, wherebyan alert may be raised and/or the cube service may exit to allow themirror cube service to take over. The cube service may also take action(e.g., raise an alert) if it detects that the cube is not synchronizedwith the SQL database. Otherwise the cube service continues to handlenotifications until notified to stop at step 412.

Exemplary Networked and Distributed Environments

One of ordinary skill in the art can appreciate that the variousembodiments and methods described herein can be implemented inconnection with any computer or other client or server device, which canbe deployed as part of a computer network or in a distributed computingenvironment, and can be connected to any kind of data store or stores.In this regard, the various embodiments described herein can beimplemented in any computer system or environment having any number ofmemory or storage units, and any number of applications and processesoccurring across any number of storage units. This includes, but is notlimited to, an environment with server computers and client computersdeployed in a network environment or a distributed computingenvironment, having remote or local storage.

Distributed computing provides sharing of computer resources andservices by communicative exchange among computing devices and systems.These resources and services include the exchange of information, cachestorage and disk storage for objects, such as files. These resources andservices also include the sharing of processing power across multipleprocessing units for load balancing, expansion of resources,specialization of processing, and the like. Distributed computing takesadvantage of network connectivity, allowing clients to leverage theircollective power to benefit the entire enterprise. In this regard, avariety of devices may have applications, objects or resources that mayparticipate in the resource management mechanisms as described forvarious embodiments of the subject disclosure.

FIG. 5 provides a schematic diagram of an exemplary networked ordistributed computing environment. The distributed computing environmentcomprises computing objects 510, 512, etc., and computing objects ordevices 520, 522, 524, 526, 528, etc., which may include programs,methods, data stores, programmable logic, etc. as represented by exampleapplications 530, 532, 534, 536, 538. It can be appreciated thatcomputing objects 510, 512, etc. and computing objects or devices 520,522, 524, 526, 528, etc. may comprise different devices, such aspersonal digital assistants (PDAs), audio/video devices, mobile phones,MP3 players, personal computers, laptops, etc.

Each computing object 510, 512, etc. and computing objects or devices520, 522, 524, 526, 528, etc. can communicate with one or more othercomputing objects 510, 512, etc. and computing objects or devices 520,522, 524, 526, 528, etc. by way of the communications network 540,either directly or indirectly. Even though illustrated as a singleelement in FIG. 5, communications network 540 may comprise othercomputing objects and computing devices that provide services to thesystem of FIG. 5, and/or may represent multiple interconnected networks,which are not shown. Each computing object 510, 512, etc. or computingobject or device 520, 522, 524, 526, 528, etc. can also contain anapplication, such as applications 530, 532, 534, 536, 538, that mightmake use of an API, or other object, software, firmware and/or hardware,suitable for communication with or implementation of the applicationprovided in accordance with various embodiments of the subjectdisclosure.

There are a variety of systems, components, and network configurationsthat support distributed computing environments. For example, computingsystems can be connected together by wired or wireless systems, by localnetworks or widely distributed networks. Currently, many networks arecoupled to the Internet, which provides an infrastructure for widelydistributed computing and encompasses many different networks, thoughany network infrastructure can be used for exemplary communications madeincident to the systems as described in various embodiments.

Thus, a host of network topologies and network infrastructures, such asclient/server, peer-to-peer, or hybrid architectures, can be utilized.The “client” is a member of a class or group that uses the services ofanother class or group to which it is not related. A client can be aprocess, e.g., roughly a set of instructions or tasks, that requests aservice provided by another program or process. The client processutilizes the requested service without having to “know” any workingdetails about the other program or the service itself.

In a client/server architecture, particularly a networked system, aclient is usually a computer that accesses shared network resourcesprovided by another computer, e.g., a server. In the illustration ofFIG. 5, as a non-limiting example, computing objects or devices 520,522, 524, 526, 528, etc. can be thought of as clients and computingobjects 510, 512, etc. can be thought of as servers where computingobjects 510, 512, etc., acting as servers provide data services, such asreceiving data from client computing objects or devices 520, 522, 524,526, 528, etc., storing of data, processing of data, transmitting datato client computing objects or devices 520, 522, 524, 526, 528, etc.,although any computer can be considered a client, a server, or both,depending on the circumstances.

A server is typically a remote computer system accessible over a remoteor local network, such as the Internet or wireless networkinfrastructures. The client process may be active in a first computersystem, and the server process may be active in a second computersystem, communicating with one another over a communications medium,thus providing distributed functionality and allowing multiple clientsto take advantage of the information-gathering capabilities of theserver.

In a network environment in which the communications network 540 or busis the Internet, for example, the computing objects 510, 512, etc. canbe Web servers with which other computing objects or devices 520, 522,524, 526, 528, etc. communicate via any of a number of known protocols,such as the hypertext transfer protocol (HTTP). Computing objects 510,512, etc. acting as servers may also serve as clients, e.g., computingobjects or devices 520, 522, 524, 526, 528, etc., as may becharacteristic of a distributed computing environment.

Exemplary Computing Device

As mentioned, advantageously, the techniques described herein can beapplied to any device. It can be understood, therefore, that handheld,portable and other computing devices and computing objects of all kindsare contemplated for use in connection with the various embodiments.Accordingly, the below general purpose remote computer described belowin FIG. 6 is but one example of a computing device.

Embodiments can partly be implemented via an operating system, for useby a developer of services for a device or object, and/or includedwithin application software that operates to perform one or morefunctional aspects of the various embodiments described herein. Softwaremay be described in the general context of computer executableinstructions, such as program modules, being executed by one or morecomputers, such as client workstations, servers or other devices. Thoseskilled in the art will appreciate that computer systems have a varietyof configurations and protocols that can be used to communicate data,and thus, no particular configuration or protocol is consideredlimiting.

FIG. 6 thus illustrates an example of a suitable computing systemenvironment 600 in which one or aspects of the embodiments describedherein can be implemented, although as made clear above, the computingsystem environment 600 is only one example of a suitable computingenvironment and is not intended to suggest any limitation as to scope ofuse or functionality. In addition, the computing system environment 600is not intended to be interpreted as having any dependency relating toany one or combination of components illustrated in the exemplarycomputing system environment 600.

With reference to FIG. 6, an exemplary remote device for implementingone or more embodiments includes a general purpose computing device inthe form of a computer 610. Components of computer 610 may include, butare not limited to, a processing unit 620, a system memory 630, and asystem bus 622 that couples various system components including thesystem memory to the processing unit 620.

Computer 610 typically includes a variety of computer readable media andcan be any available media that can be accessed by computer 610. Thesystem memory 630 may include computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) and/orrandom access memory (RAM). By way of example, and not limitation,system memory 630 may also include an operating system, applicationprograms, other program modules, and program data.

A user can enter commands and information into the computer 610 throughinput devices 640. A monitor or other type of display device is alsoconnected to the system bus 622 via an interface, such as outputinterface 650. In addition to a monitor, computers can also includeother peripheral output devices such as speakers and a printer, whichmay be connected through output interface 650.

The computer 610 may operate in a networked or distributed environmentusing logical connections to one or more other remote computers, such asremote computer 670. The remote computer 670 may be a personal computer,a server, a router, a network PC, a peer device or other common networknode, or any other remote media consumption or transmission device, andmay include any or all of the elements described above relative to thecomputer 610. The logical connections depicted in FIG. 6 include anetwork 672, such local area network (LAN) or a wide area network (WAN),but may also include other networks/buses. Such networking environmentsare commonplace in homes, offices, enterprise-wide computer networks,intranets and the Internet.

As mentioned above, while exemplary embodiments have been described inconnection with various computing devices and network architectures, theunderlying concepts may be applied to any network system and anycomputing device or system in which it is desirable to improveefficiency of resource usage.

Also, there are multiple ways to implement the same or similarfunctionality, e.g., an appropriate API, tool kit, driver code,operating system, control, standalone or downloadable software object,etc. which enables applications and services to take advantage of thetechniques provided herein. Thus, embodiments herein are contemplatedfrom the standpoint of an API (or other software object), as well asfrom a software or hardware object that implements one or moreembodiments as described herein. Thus, various embodiments describedherein can have aspects that are wholly in hardware, partly in hardwareand partly in software, as well as in software.

The word “exemplary” is used herein to mean serving as an example,instance, or illustration. For the avoidance of doubt, the subjectmatter disclosed herein is not limited by such examples. In addition,any aspect or design described herein as “exemplary” is not necessarilyto be construed as preferred or advantageous over other aspects ordesigns, nor is it meant to preclude equivalent exemplary structures andtechniques known to those of ordinary skill in the art. Furthermore, tothe extent that the terms “includes,” “has,” “contains,” and othersimilar words are used, for the avoidance of doubt, such terms areintended to be inclusive in a manner similar to the term “comprising” asan open transition word without precluding any additional or otherelements when employed in a claim.

As mentioned, the various techniques described herein may be implementedin connection with hardware or software or, where appropriate, with acombination of both. As used herein, the terms “component,” “module,”“system” and the like are likewise intended to refer to acomputer-related entity, either hardware, a combination of hardware andsoftware, software, or software in execution. For example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration, both an application runningon computer and the computer can be a component. One or more componentsmay reside within a process and/or thread of execution and a componentmay be localized on one computer and/or distributed between two or morecomputers.

The aforementioned systems have been described with respect tointeraction between several components. It can be appreciated that suchsystems and components can include those components or specifiedsub-components, some of the specified components or sub-components,and/or additional components, and according to various permutations andcombinations of the foregoing. Sub-components can also be implemented ascomponents communicatively coupled to other components rather thanincluded within parent components (hierarchical). Additionally, it canbe noted that one or more components may be combined into a singlecomponent providing aggregate functionality or divided into severalseparate sub-components, and that any one or more middle layers, such asa management layer, may be provided to communicatively couple to suchsub-components in order to provide integrated functionality. Anycomponents described herein may also interact with one or more othercomponents not specifically described herein but generally known bythose of skill in the art.

In view of the exemplary systems described herein, methodologies thatmay be implemented in accordance with the described subject matter canalso be appreciated with reference to the flowcharts of the variousfigures. While for purposes of simplicity of explanation, themethodologies are shown and described as a series of blocks, it is to beunderstood and appreciated that the various embodiments are not limitedby the order of the blocks, as some blocks may occur in different ordersand/or concurrently with other blocks from what is depicted anddescribed herein. Where non-sequential, or branched, flow is illustratedvia flowchart, it can be appreciated that various other branches, flowpaths, and orders of the blocks, may be implemented which achieve thesame or a similar result. Moreover, some illustrated blocks are optionalin implementing the methodologies described hereinafter.

Conclusion

While the invention is susceptible to various modifications andalternative constructions, certain illustrated embodiments thereof areshown in the drawings and have been described above in detail. It shouldbe understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

In addition to the various embodiments described herein, it is to beunderstood that other similar embodiments can be used or modificationsand additions can be made to the described embodiment(s) for performingthe same or equivalent function of the corresponding embodiment(s)without deviating therefrom. Still further, multiple processing chips ormultiple devices can share the performance of one or more functionsdescribed herein, and similarly, storage can be effected across aplurality of devices. Accordingly, the invention is not to be limited toany single embodiment, but rather is to be construed in breadth, spiritand scope in accordance with the appended claims.

1-20. (canceled)
 21. An apparatus, comprising: a logic circuit; andlogic operative on the logic circuit to communicate a Structured QueryLanguage (SQL) query to a SQL database to determine the state of anactive read cube, and direct the SQL query to a passive read cube whenthe active read cube is not operational or is being synchronized withwrite data from an active processing cube or from a passive processingcube if the active processing cube is not available.
 22. The apparatusof claim 21, wherein the logic is further operative to write datachanges to the active processing cube or to the passive processing cubeif the active processing cube is not operational.
 23. The apparatus ofclaim 21, wherein the SQL database comprises a mirrored SQL database.24. The apparatus of claim 21, wherein in the event that thesynchronization is occurring on the active read cube and the passiveread cube is not operational, the logic further operative to block readqueries.
 25. An apparatus, comprising: a primary read server coupled toa primary read cube, the primary read server configured to handleincoming read queries by returning data from the primary read cube; abackup read server coupled to a backup read cube for the primary readcube, the backup read server configured to handle incoming read queriesby returning data from the backup read cube in response to a failoveroccurrence; a primary processing server coupled to a cube service and aprimary write cube, the cube service configured to write data changes inthe database to the primary write cube and to synchronize at least oneof the primary read cube or the backup read cube based on the datachanges; and a backup processing server coupled to a backup cube serviceand a backup write cube for the primary write cube, the backup cubeservice configured to write the data changes to the backup write cubeand to synchronize at least one of the primary read cube or backup readcube in response to a failover occurrence.
 26. The apparatus of claim25, wherein at least one of the primary read cube, the backup read cube,the primary write cube, or the backup write cube comprises ann-dimensional database structure.
 27. The apparatus of claim 25, whereinthe backup processing server further configured to synchronize at leastone of the primary read cube or backup read cube with the data changeswhen the primary processing server or the primary processing cube is notavailable or is not operational.
 28. The apparatus of claim 25, whereinthe backup processing server further configured to return data from thebackup read cube when the primary read server is not operational or whenthe primary read cube is being synchronized.
 29. The apparatus of claim25, wherein the cube service configured to restore a database from abackup and rebuild the primary read cube from the database.
 30. Theapparatus of claim 25, wherein the primary processing server writes aschedule of operations to the database, the backup cube service furtherconfigured to access the schedule of operations to perform one or moreoperations of the schedule when the primary processing server is notoperational.
 31. The apparatus of claim 25, wherein the primaryprocessing server writes state information to a database that indicateswhen a synchronization of the primary read server is in progress andthat indicates when a synchronization of the primary read server is notin progress.
 32. The apparatus of claim 25 further comprising a frontend server including logic configured to access state information in adatabase and direct read queries to the backup read server when thestate information indicates that synchronization of the primary readserver is in progress.
 33. The apparatus of claim 25, wherein the cubeservice synchronizes the backup write cube based on the data changes ina database in a first synchronization operation, synchronizes the backupread cube in a second synchronization operation, and synchronizes theprimary read cube in a third synchronization operation.
 34. Theapparatus of claim 25, wherein the primary read server corresponds to afirst computing machine or cluster, wherein the backup read servercorresponds to a second computing machine or cluster, wherein theprimary processing server corresponds to a third computing machine orcluster, wherein the backup processing server corresponds to a fourthcomputing machine or cluster, wherein the first machine or cluster,second machine or cluster, third machine or cluster and fourth machineor cluster are physically separate from one another.
 35. The apparatusof claim 25, wherein the cube service writes a first timestampcorresponding to the time of synchronization of the read cube to adatabase, and writes a second timestamp corresponding to the time ofsynchronization of the read cube to the write cube, and wherein the cubeservice is configured to compare the first and second timestamps witheach other before a next synchronization to determine whether the writecube and the read cube are still synchronized,.
 36. The apparatus ofclaim 25, wherein the cube service performs an incrementalsynchronization of the write cube and the read cube when the first andsecond timestamps indicate the write cube and the read cube are stillsynchronized, or performs full cube processing when the first and secondtimestamps indicate the write cube and the read cube are not stillsynchronized.
 37. A computer-implemented method performed at least inpart on at least one processor, comprising: processing read queriesdirected to an active read cube at an active read server, includingquerying a database at a first read server to determine a state of afirst read cube, and if the first read cube is active, directing theread queries to the first read server, and if not, directing the readqueries to a second read server having a second read cube; synchronizinga first write cube or a second write cube of a first write processingserver or a second write processing server, respectively, with datachanges to the database based on whether the first write cube or thefirst write processing server is operational; and synchronizing changedata corresponding to the data changes with at least one of the firstread cube or the second read cube.
 38. The method of claim 37 furthercomprising writing state information to the database that indicates asynchronization of the first read cube in progress.
 39. The method ofclaim 37 further comprising rebuilding the first read cube with arestored database from a backup.
 40. The method of claim 39 furthercomprising restoring the database using a mirrored SQL database as abackup for the database.